2.2. Takeaways

1. We would like to clarify wording in standard such that when an RRULE is modified, the SEQUENCE number MUST be incremented (some implementations reset to 0), specifically Microsoft Exchange. This seems that it could probably be changed very easily by Microsoft, and would have little to no risk in causing any regressions. Incrementing the RRULE allows other implementations to treat the change as an update rather than forcing the entire series to be blown away and recreated.

2. We would like to explore the concept of a iCalendar diff format. This would be a single VEVENT that contains ONLY data that was modified by that update. This probably requires some property level sequence tracking to correctly apply notices that arrive out of date. Many implementations already have such capabilities but do not share them in a standardized fashion. This would make update/reschedule transactions much simpler and much smaller. Additionally, it would conceptually be able to interoperate well with varying data models. Follow up is needed as to the specifics of this.

3. We would like to explore the concept of adding a SERIES ID to the iCalendar spec so that multiple UIDs could still be considered part of the same series. This would help in the implementation of THISANDFUTURE. Currently, the only ways to truly represent THISANDFUTURE changes are:

   • Modification of each effected instance as an exception

   • Dynamic processing of data

   • Splitting the meeting into multiple UIDs for each split. At this point, a subsequent THISANDFUTURE call across the two modified sets becomes problematic and there remains problems linking the two separate UIDs as they are actually representing the same meeting.

4. IBM would like to re-add the deprecated THISANDPRIOR, as Notes/Domino does utilize this and is reliant upon it. It should be added as an addendum to RFC 5545 and remain in consideration as implementations handle THISANDFUTURE going forward.